IBIS Macromodel Task Group Meeting date: 08 October 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Kumar Keshavan Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Stephen Slater Maziar Farahmand * Todd Bermensolo Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz * Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None ------------- Review of ARs: - Ambrish to look into adding graphic or improved example to BIRD197.5. - In progress. - Randy to add "post-process" versus "post process" to the IBIS 7.0 known issues document. - In progress. - Randy and Michael M. to invite DDR memory and controller vendors to comment on new protocols. - In progress. Arpad asked if this topic was still relevant and needed to be an active AR. He noted that at the previous meeting someone had mentioned that JEDEC, for example, isn't getting involved in writing specs like this. Walter noted that he had thought JEDEC meetings might be a good place to invite people to contribute, even if JEDEC itself didn't get involved with this sort of discussion directly. Walter thought the AR should stay open because we need to get other memory and controller vendors involved in the DDR5 DQ Write protocol discussions. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the October 1 meeting. Walter moved to approve the minutes. Bob seconded the motion. There were no objections. ------------- New Discussion: New Attendee: - Todd Bermensolo of Keysight introduced himself. He is interested in AMI modeling. His experience has been on the creation and usage side, and now he is gaining experience on the EDA tool side of the process. BIRD197.5 DC_Offset: Arpad asked if the current status is that we are waiting for a new draft version in which DC_Offset is an In parameter only. Walter and Ambrish agreed. Walter noted that he had produced a version, and Ambrish was going to add an example. Ambrish noted that Fangyi had also had comments on Walter's version. Walter suggested that once we have Ambrish's example we can work on further clarifying the language. Arpad said this topic would be continued next week. BIRD198.1: Arpad noted that the authors had sent us a response to our earlier feedback. He noted that Walter had prepared some slides for this meeting to continue the discussion. Randy noted that we had asked the authors to provide an example of the use of a Model_Selector. The authors had replied that they really wanted this feature, and they provided an example of a DDR3/4 combo phy where the on-die capacitance value would change between the two modes. Another example was power-gating affecting the value of the on-die capacitance. Walter presented a new proposed syntax designed to meet the authors' requirements. He proposed a new [PDN Group] keyword, each of which could include multiple PDN models. He noted that he had tried to use names similar to BIRD189. He noted one idea he had was to designate on particular Group as the PDN models which would be used in combination with a BIRD189 interconnect model. Walter noted that each model contains a C and two Rs (series and parallel). Walter thought corners should always be typ/slow/fast as opposed to typ/min/max but noted this was up for debate. Arpad noted that in our response we had asked the authors if they included magnitude based typ/min/max corners and typ/slow/fast corners simply to be consistent with the rest of the spec, or if there was a need for both. He expressed concern that the authors may not have understood the question. He noted that in the latest response they had removed typ/min/max corners from their proposal, but they had left the C_pdn, etc., names without the _corner suffix. So they now had typ/slow/fast corner values, but the parameter names without _corner looked more like the typ/min/max version of the C_comp parameters. Randy agreed that there might have been confusion in the correspondence. He noted that he thought there really only needed to be one way to specify the corners, but we need to make it clear and be clear that any column selection applies to the C and both the R values. Walter added _corner to the names in his proposal. Randy noted that he would prefer the name [On Die PDN Group] for the keyword. Bob said he preferred that we not use "Group" at all in this context but said he didn't yet have an alternative. Bob asked if there was in fact a need to support both. He asked if decoupling capacitors had strong and weak values that were tied with the silicon process, or are they separate discrete components not tied to silicon. If both possibilities exist, then we might need both types of corners. Randy noted that corners for these PDN components might not align with transistor behavior at all. Arpad and Bob noted that we might want to preserve both types of corners if this were the case. Arpad asked if we needed a typ/min/max version. Walter said we had typ/min/max for C_comp only because the spec originally defined it that way. Bob noted that C_comp tracked silicon process and having the original typ/min/max version was probably a mistake. Arpad said it was not a mistake, and he noted that when C_comp was first defined in the spec it was intended to include both the transistor parasitics as well as the parasitics of the metal conductors which are placed between the transistors and the die pads. The capacitance of these metal layers does not track the silicon process variations. Arpad noted that he was not familiar with how on-die PDN circuits are implemented today, so he wasn't sure how they should be modeled correctly for these corner cases. Randy said he didn't think the typ/min/max version made much sense, since when the model maker is creating a model they want to ensure corresponding values of the parameters are used together. If you choose one column (typ/slow/fast) you should get that same columns value for all the parameters. Arpad said that if PDN values didn't vary with the silicon process we might need typ/min/max too. Walter's syntax example contained two PDN Groups, each of which contained two PDN decoupling models, one for VSSA and one for VSSB. He modified the example so that one Group used typ/slow/fast keywords with the _corner suffix, and the other example used typ/min/max keywords without the _corner. Arpad noted that it was understood that for typ/slow/fast keywords you should get the value from the same column for each of the parameters (i.e., the user/tool should not mix C_pdn slow with R_pdn fast, etc.). He suggested that we should add a similar statement for the typ/min/max corner values. Bob, however, wondered if we should allow tools to mix the typ/min/max versions to create best or worst case decoupling at their discretion. Walter said he would send the modified proposal presentation to Arpad, Randy, Bob, and Mike L. for further discussion prior to responding to the authors. Enabling Back-channel in Statistical Mode: Walter reviewed his Impulse Optimization Training presentation, which summarized the previous discussions and the options. - Alternatives (slide 2): - Iterate AMI_Init(). - Iterate a new AMI_Impulse() function. - do nothing... - Do we want to formalize a way for EDA tools to iterate one of these two functions to enable IC Vendors (model makers) to optimize/train a channel using IR processing? Arpad noted that he had spoken with Vladimir about the proposal, and Vladimir felt with should leave the optimization routines up to the EDA vendors. If the model maker still wanted to do their own optimization, then they could handle it with a proprietary scheme. This would likely imply that the Tx and Rx came from the same vendor and could communicate. He feared the spec would have to be too long and detailed if it were to describe how this communication takes place. Walter said we do that already with BIRD147. BIRD147 says the Tx and the Rx can agree to communicate via a protocol of their choosing. This proposal would simply extend that capability to AMI IR processing instead of waveform processing. Arpad noted questions about what would be used as the eye metric (eye opening, SNR, etc.) and asked whether it was possible to describe those in a BIRD147 type protocol. Walter said it was, and noted that his earlier presentation had included some possible approaches for the DDR5 DQ Write protocol. The protocol could specify how the Rx generates the eye metric, or an alternative method would be to have the Rx send its modified IR back to the Tx so the Tx could handle computing the eye metric. Wei-hsing said he agreed with Arpad. There are many ways the Tx and Rx could communicate. The Tx .dll could even load the Rx .dll itself and directly handle the optimization. Walter noted that the goal was to model the optimization done by the Tx in the real system. - Iterate Existing AMI_Init() (slide 4) - Done by EDA tools now. - Blind sweeps - Intelligent sweeps - User input - AMI_Init() would need to maintain history. EDA tool would have to call AMI_Init() differently the first time. - Iterate AMI_Impulse (slide 5) - Could be a more efficient version of iterating with AMI_Init(), since AMI_Impulse() would maintain the history in memory. - Do nothing (slide 6) - IC Vendors and EDA vendors would deliver proprietary solutions. - Do IC Vendors want that, or do they want standardized AMI models that should give the same answer on all tools? Mike L noted that the AMI_memory_handle passed in to AMI_Init() is a pointer to the memory block allocated by the model. One the first call to AMI_Init() what it points to is expected to be null. On subsequent calls the handle would instead point to the block returned by the initial call to AMI_Init(). Radek agreed that this was all that was needed to iterate with AMI_Init(). Walter agreed that this was one solution. He noted that AMI_Resolve() could have been handled the same way, but we had instead added the new AMI_Resolve() function. - Mike L.: Motion to adjourn. - Radek: Second. - Arpad: Thank you all for joining. AR: Walter to send today's modified BIRD198 syntax proposal to Bob, Randy and Arpad, and Mike L. ------------- Next meeting: 15 October 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives